Because network equipment is continually evolving, and because of the number and variety of technologies that are employed by the equipment and the number and variety of services that are offered to customers using the networks and the equipment, network operators are increasingly confronted with priority and level of service management problems. There is even more of a problem if a network operator enters into Service Level Agreements (SLA) with its customers that include Service Level Specifications (SLS).
Several types of integrated network management tools, also known as Operation Support Systems (OSS), intended to facilitate the task of operators have been proposed. They include quality of service management modules that deliver alarm messages (for example SNMP TRAP messages) if a problem (or an event) that has occurred or is likely to occur and that impacts on the network equipment or network performance is detected. An alarm message is usually communicated to a network manager, who determines actions likely to solve the problem that is giving rise to the alarm message. These tools also include traffic engineering modules that execute commands corresponding to actions determined by a network manager.
The solution described in the patent application WO 00/74314 is a mechanism for managing problems within a network with a view to providing solutions to them. The types of solution cited (on page 2) include problem reporting, problem notification, service level agreement (SLA) violations, reconfiguration of the service affected by the problem detected, etc. The solution is focused on the service aspect and takes no account of the behavior of the network as such (the data streams transmitted, the distribution of the load on the network elements, etc.).
Thus it is not a matter of interfacing this mechanism to a traffic engineering module.
Similarly, the patent application WO 00/72183 is concerned with the service management level and is silent on the problems of network management as such. Although that document mentions the possibility of reconfiguration, that is triggered by an SLA violation, not by alarms from the network or the status of the network.
There are a few tools enabling a network manager to view some alarms, and thus providing management aids. However, there is no decision making aid capable of proposing actions on traffic engineering modules. The manager must therefore analyze all the alarm messages delivered by various quality of service management modules, which usually have different formats, then classify them in priority order, then decide the actions to be taken, on the basis of the current traffic, and finally generate commands, usually having different formats, so that the traffic engineering modules can undertake those actions.
The manager must therefore be capable of i) analyzing large quantities of information in time periods that are often short, ii) interpreting all the events reported by the various management modules, and iii) configuring all the available traffic engineering modules, and must consequently be familiar with all of the commands that these modules use. These operations divert the manager from his main function, which is solving problems associated with network events. What is more, these operations are often time-consuming and repetitive.
From another point of view, integrating a new traffic engineering module into a group of OSS components is a complex task in that, firstly, the programming language interfaces (API) used so that the different software entities can coexist are frequently mutually incompatible and, secondly, the events of interest to this kind of module generally originate from many heterogeneous software tools, with the result that it is necessary to take account of all traffic load modifications and forecasts and constraints associated with the network equipment (for example an interface that is out of service) or network capacity modifications.